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Description 

SYSTEM AND METHOD FOR THE 
PROCESSING OF MICR DOCUMENTS 
THAT PRODUCE READ ERRORS 

Background of Invention 

[0001] Financial institutions have established various processes 
and associations related to the exchange of documents 
evidencing monetary transactions. Such documents are 
generally encoded with magnetic ink so that information 
from the documents can be read by machine. Such docu- 
ments have thus become known as magnetic ink character 
recognition (MICR) documents. Check processing and 
sorting systems have also been developed in which a 
check or similar MICR document has its image captured 
and stored electronically. Such an image can be archived 
so that it is indexed or joined with its accompanying data 
from a MICR read. In addition, up until now, MICR docu- 
ments have also been captured photographically for stor- 
age in microfilm format. This feature is being removed as 



electronic image processing and retrieval replaces the use 
of microfilm. 

[0002] The typical high-speed processing of documents having 
MICR data, for example, checks, includes reading and 
storing a MICR line, endorsing the document with applica- 
ble information, imaging the item so that the image can 
be stored in an archive facility, and sorting items for pro- 
cessing. Items for which the MICR reads properly, and for 
which no errors are detected in the data, sort to pockets 
for routine processing. Any items with a failed MICR read 
or an exception are typically sorted to a reject pocket and 
are handled through an exception process. The exception 
process typically includes attempting to read the MICR 
with an alternate, slower type of reader to achieve a better 
read rate, and if that fails, manually reviewing the paper 
document and keying in the appropriate data. 

[0003] pig. 1 is a flow chart which illustrates the current process 
for processing MICR documents at many financial institu- 
tions. In Fig. 1, various steps in the process are repre- 
sented by process blocks. Process blocks can also repre- 
sent stopping points or paths for different types of items. 
At block 102, items with MICR data are loaded into a 
high-speed processor. The MICR data on the item is rec- 



ognized and captured by a read head. The data is trans- 
ferred to a file for storage with indicators that signify 
which fields have apparently read correctly, and which 
ones have failed to read. Logic failures are also detected. 
A logic failure occurs when data has apparently been cap- 
tured successfully, but makes no sense, so it must be as- 
sumed that the data as captured is erroneous. At block 
102 of Fig. 1, items also typically pass through an en- 
dorsement feature, which typically puts a date, location of 
scan, and other data related to the financial institution 
performing the processing. The item optionally can move 
through a microfilm unit to have a photographic image 
captured. Next, the item moves under and over image 
scanners. An image of the item (front and back) is created 
and stored. 

[0004] At block 104, based on the read of the document, instruc- 
tions are executed regarding the disposition of the item. 
All items with read failures or logic issues are passed to a 
reject pocket at block 106. A correction process then 
takes place at block 108. Where an item reads good, with 
good data, at block 104, the item goes through high 
speed pocketing at block 110. In a typical check process- 
ing environment, based on the read of the MICR data, 



items are sorted into pockets as "on-us" items, as shown 
at block 112, or "transit" items, as shown at block 114. An 
on-us item is an item that is drawn on the financial insti- 
tution doing the processing. On-us items will typically be 
forwarded to other locations within the financial institu- 
tions own franchise. Transit items are checks drawn on 
other financial institutions, and are pocketed for delivery 
to those institutions. 

[0005] The data correction process, 108, also results in items 
eventually being sorted into corrected, on-us items 116, 
and corrected, transit items, 118. Items from the high- 
speed process are then merged, eventually, with items 
from the correction or "reject repair" process at block 120. 
Thus, both the reject items and the good items, are typi- 
cally eventually sorted to their destinations, shown con- 
solidated at blocks 122 and 124. 

[0006] | n a typical financial institution, large numbers of MICR 
items must go through the correction process, since any 
error in the read of any field causes an item to sort to a 
reject pocket. In many cases, the correction process in- 
cludes the use of check mender equipment to place cor- 
rection strips on the bottom of each document so new, 
readable MICR can be placed on each document. The re- 



suiting delay considerably reduces the processing time for 
each batch of MICR items processed by a financial institu- 
tion. 

Summary of Invention 

[0007] The present invention, disclosed herein by way of example 
embodiments, can improve the processing time for large 
numbers of MICR encoded documents within a financial 
institution. Through use of an embodiment of the inven- 
tion, the number of items which are pocketed as rejects 
can be significantly reduced. This reduction can be ac- 
complished due to the realization that only the routing/ 
transit field from the MICR data of an item needs to be 
read correctly in order for it to be properly pocketed. Ad- 
ditionally, speed of correction for documents which are 
pocketed as rejects is improved through the use of an im- 
age based correction process which can be referred to 
herein as MICR image correction or "MIC." Embodiments 
of the invention can also be used to correct image data 
received electronically when paper documents have been 
scanned elsewhere. 

[0008] According to some embodiments of the invention, a 

method of processing a MICR encoded document and/or 
its image, where the document has produced one or more 



errors in a stored data field includes the receiving of an 
image of the document and an optical character recogni- 
tion (OCR) process that is performed on the stored, elec- 
tronic image. The portion of the document to which the 
OCR process is applied corresponds to the stored data 
field. For example, if the error is related to an account 
number, the OCR process is performed on a snippet of the 
document that includes the account number. Where paper 
items have been received and stored locally, the process 
may begin with the imaging of the document. An example 
method of the invention in such a case can further include 
routing the document to a destination pocket and subse- 
quently to a destination subject to a determination that 
the error(s) do(es) not prevent the routing of the docu- 
ment. In typical embodiments, an error does not prevent 
the routing of the document if it is not related to the rout- 
ing/transit field. Embodiments of the correction process 
can be applied to image data received from another insti- 
tution which scanned the MICR documents. 
[0009] The OCR process result is used to apply a correction to 
the error in the stored data field. This correction can be 
based on a comparison of the result of the OCR process 
and the digits within the stored data field which have been 



captured, albeit only partially or incorrectly. If a determi- 
nation is made that the correction cannot be successfully 
determined by the comparison with the result of the OCR 
process, the image and MICR data is displayed on a user 
terminal, for manual correction, albeit by reference to an 
image of the document, rather than the document itself. 

[0010] | n some embodiments, an improved correction process 
can be applied when the error appears in a stored data 
field which has two or more corresponding areas within 
the image of the item. For example, if the error is in an 
amount, two results of an OCR process can be used. One 
result can be obtained from optically scanning the MICR 
line, and another result can be obtained from optically 
scanning a written amount. In some cases, still another 
OCR process result can be obtained if the amount is listed 
both numerically, and written out. 

[0011] a system for processing MICR encoded documents ac- 
cording to embodiments of the invention can include a 
sorter to sort and read the documents and route docu- 
ments to a destination pocket when an error in a stored 
data field does not prevent the routing. Such a sorter can 
be operatively interconnected with a computing platform 
to provides the OCR processing and apply corrections to 



the error in the stored data field based on a comparison 
of the result of an OCR process and the data in the stored 
field. The computing platform can also provide for the 
storage and routing of the images for manual correction 
at user terminals as required. Computer program instruc- 
tions, computer programs or computer code, possibly in 
the form of a computer program product can implement 
portions of the invention. These computer program code 
instructions can operate a computing platform which con- 
trols a sorter and other hardware within the system. With 
such a system, the handling of physical items in order to 
perform reject repair can be eliminated. Furthermore, 
many items having errors, specifically errors which do not 
prevent the routing of the items, can be routed to a desti- 
nation and any error correction required, whether auto- 
mated or manual, can be performed using only the images 
of the items. Additionally, data referring to documents 
that were scanned elsewhere can be corrected. Thus, 

overall check processing time can be reduced. 
Brief Description of Drawings 

[0012] pig. 1. is a flow diagram which illustrates a process in 
which all MICR encoded items having MICR failures or 
other errors are routed to a reject pocket for a physical 



data correction process. 

[0013] pig. 2. is a flow diagram which illustrates the processing 
of items according to embodiments of the invention. 

[0014] pig. 3. is a flow chart which illustrates a method of pro- 
cessing items according to some embodiments of the in- 
vention. 

[0015] Fig. 4. is a block diagram of a system which handles MICR 
encoded items according to some embodiments of the in- 
vention. 
Detailed Description 

[0016] The present invention will now be described in terms of 
specific, example embodiments. It is to be understood 
that the invention is not limited to the example embodi- 
ments disclosed. It should also be understood that not 
every feature of the methods and systems described is 
necessary to implement the invention as claimed in any 
particular one of the appended claims. Various elements 
and features of various embodiments are described to 
fully enable the invention. It should also be understood 
that throughout this disclosure, where a process or 
method is shown or described, the steps of the method 
may be performed in any order or simultaneously, unless 
it is clear from the context that one step depends on an- 



other being performed first. With respect of flow charts, 
block diagrams and flow diagrams, not every possible sig- 
nal flow, data path, or process block is shown. Rather, for 
clarity, only those important to the inventive concepts be- 
ing discussed relative to the drawing may be illustrated, 
although others may be discussed in this description. 

[0017] The meaning of certain terms as used generally in the 
context of this disclosure should be understood as fol- 
lows. Terms such as "document" or "MICR encoded docu- 
ment" and the like are meant to refer to any document 
which tends to be handled and sorted in large volumes 
based on MICR information printed thereon. In the typical 
context, such documents are checks which order a bank 
to pay a certain sum to the order of another individual or 
entity. However, other documents evidencing financial 
transactions relating to banking, and for that matter, 
other kinds of documents, can be "MICR encoded docu- 
ments." Even in the typical banking context, deposit slips 
are sometimes MICR encoded, read and sorted in a fash- 
ion similar to checks. 

[0018] Terms like "bank" and "financial institution" are used 

herein in their broadest sense. Financial institutions that 
process transactions and documents of the types dis- 



cussed can include stock brokerages, credit unions, and 
other types of institutions which are not strictly "banks" in 
the historical sense. The use of terms such as "bank" or 
"financial institution" herein is meant to encompass all 
such possibilities. 
[0019] References will be made at various places within this dis- 
closure to information contained in a "stored data field" or 
information within such a field being "corrected." As pre- 
viously discussed, this terminology refers to the idea of 
correcting information about MICR encoded documents 
which is stored in data structures for retrieval and manip- 
ulation. There are many ways to design a system to ac- 
commodate the storage of this information, as well as the 
storage of electronic images of documents such as 
checks. Reference will be made herein to updating strings 
and user bytes which either are or refer to such fields in 
systems which process MICR documents such as checks. 
In example embodiments, this terminology refers to infor- 
mation stored in what is commonly known as a "check im- 
age management system" (CIMS) and within a "check pro- 
cessing control system" (CPCS). Such systems are well 
known within the banking industry by those who work in 
the financial data processing fields. Such data processing 



systems have historically been produced by the Interna- 
tional Business Machines Corporation and marketed to 
banking and financial companies. Through the use of such 
systems, check images and index information referring to 
the check images, which typically includes the MICR data, 
can be stored in a single file according to an industry 
standard "check image export" (CIE) format. CIE has been 
used for many years by many banks to archive check im- 
ages for their own internal use. Images and index infor- 
mation in such a system can be stored in the same file or 
separated. In some environments, the index information is 
separated and stored in an electronic cash letter (ECL) for 
communicating between financial institutions for the pur- 
pose of settlement. Index information can also be stored 
with electronic images in an "image cash letter" (ICL) to 
provide for the truncation of the paper documents. Again, 
these systems and techniques are well known by those of 
ordinary skill in the financial information technology arts. 
[0020] pig. 2 is a flow diagram and process diagram which illus- 
trates the flow, 200, of items according to some embodi- 
ments of the invention. Fig. 2 also shows some of what 
happens to stored MICR data according to some embodi- 
ments of the invention. Further detail on how the data is 



handled is covered in Figs. 3 and 4. At block 202 of Fig. 2, 
MICR encoded items are loaded into a high-speed proces- 
sor. As before, the processor reads the MICR data and the 
data is transferred to a file for storage. An item is en- 
dorsed, an image is created and stored, and in some 
cases, a photographic image is made for microfilm pur- 
poses. Block 203 represents an incoming image file from 
another financial institution. The logic for the correction 
process is the same as with paper processing. The incom- 
ing information may only be electronic as the future of 
check processing changes from paper to image. The MICR 
data for the images as captured by the sending bank may 
still contain MICR digits errors from the sending bank 
MICR capture equipment. The correction process will still 
follow the logic as described in Fig. 2 using the same im- 
age and image technology, only without on-us paper and 
without any transit images or items. As before, a determi- 
nation is made at block 204 as to whether the item reads 
or was read good. If a locally sorted paper item reads 
good, it is pocketed at block 206. Pockets eventually 
break down into a sort of items into on-us items at block 
208, and transit items at block 210. In the example of Fig. 
2, good items also cause a valid user byte to be generated 



in the CIMS/CPCS system at block 212. 

[0021] | n process 200 of Fig. 2, a determination is made at block 
214 as to the type of error, which occurred during the 
read of an item. In the case of a logic failure related to a 
locally sorted paper item, the item is routed to the tradi- 
tional physical reject process which commences at block 
216 and the item is assigned a reject user byte. If a digit 
error has occurred, that is an error in which a digit within 
a field was not able to be read, the item is again routed to 
the physical reject process if the error occurs in the rout- 
ing/transit (R/T) field and the item is assigned a reject 
user byte. In such a case, the item cannot be sorted since 
the R/T field determines the final destination of the item. 
However, if the digit failure or digit error occurs in any 
other fields related to the MICR encoded document, the 
item can still be sorted and pocketed at high-speed. Thus, 
if the error as determined at block 214 is found not to be 
a logic or routing/transit failure, the item is sorted into a 
pocket at block 206, in the same manner as a good item. 
An on-us or transit reject user byte will then be assigned 
to the item indicating the item has sorted good, but needs 
further attention for corrective purposes. 

[0022] At block 218 of Fig. 2, the MICR image correction process 



takes place. The process can be the same regardless of 
where the paper item was first read and sorted. CIMS/ 
CPCS systems will recognize all the items that have a on- 
us or transit reject user byte. It is or was known at this 
point into which pocket the item needs to be or has been 
sorted, since the information needed to sort the item is 
generally determined from the routing/transit number. 
Thus, in the case of locally sorted paper items, at the end 
of the high-speed sort, items are pocketed as on-us 
items, 208, which include good on-us items and on-us 
rejects, and transit items, 210, which include good transit 
items and transit rejects. 
[0023] As in the prior art, paper rejects are handled with a physi- 
cal reject pocketing and correction process at block 220. 
This correction process results in on-us items pocketed at 
block 222 and transit items pocketed at block 224. In 
each case, these items will now have good data stored 
within CIMS and CPCS. These items are merged with the 
high-speed sorted items at block 226. Once the process 
has been completed for a batch of MICR encoded docu- 
ments, the documents are stored in on-us pockets 228 
and transit pockets 230, where in each case the physically 
pocketed items include both good items and reject items. 



The documents can now proceed to their destinations and 
any MICR data correction necessary can be provided 
through the high-speed MICR image correction process 
according to embodiments of the invention. It should be 
noted that in the case of transit items, MICR data is fre- 
quently exchanged via an electronic cash letter in parallel 
with the presentment of paper documents. Thus, a finan- 
cial institution to which transit items are to be presented 
will be able to identify and acquire the correct MICR infor- 
mation notwithstanding the fact that the paper documents 
may not read error free. 
[0024] pig. 3 is a flow chart illustrating a process, 300, for MIC 
reject repair in an example system based on CIMS and 
CPCS. The data fields being repaired can correspond to 
paper items that were first sorted either locally, or at an- 
other institution. At block 302 the appropriate image and 
MICR information is retrieved from CIMS and CPCS. This 
MICR information includes the various stored data fields, 
and what in CIMS and CPCS parlance is referred to as a 
"string" that includes a "user byte." In example embodi- 
ments of the invention, the string designates an item as 
valid, as an on-us reject, as a transit reject. The string can 
also designate the item as simply a reject if it is a paper 



reject requiring paper reject processing in the manner of 
the prior art. At block 304 an optical character recognition 
process is performed on a snippet from the image. On a 
first pass, in example embodiments, this snippet is at 
least one portion of the image, the portion which includes 
the MICR printed numbers which correspond to the stored 
data field in question. The OCR process reads the snippet 
optically, as opposed to with a MICR read head. At block 
306, the result of the OCR process is compared with the 
MICR data in the stored data field to determine the likely, 
correct content of the field. This determination can be 
made in such a way that the probability that the field is 
actually supposed to be what is determined can be as- 
signed a confidence level. 
[0025] a system according to embodiments of the invention can 
be set up to test for a certain minimum confidence level 
as shown at block 308, before allowing a correction to be 
applied to the stored data field. In effect, the validity of 
the correction proposed is subject to having been suc- 
cessfully determined by the comparison, within a given 
confidence. This forces the system to only allow the MIC 
error correction if there is a substantial likelihood that the 
error correction will be successful in that the correct con- 



tents of the stored data field will be determined and re- 
stored. In some embodiments, required confidence levels 
can be set by the operators of a system. Assuming the 
minimum read confidence level is passed at block 308, a 
reject repair string based on the comparison of the OCR 
result and the data in the stored field is updated at block 
310. At block 312, the process repeats if there are addi- 
tional errors to be corrected. If not, as in the case where 
all needed reject repair items have been corrected, the 
image repair string(s) are merged with the MICR data at 
block 314. In example embodiments, all the corrected 
MICR data is then merged into CIMS / CPCS at block 316. 
[0026] if the minimum read confidence level is not achieved at 
block 308 of Fig. 3, a test is made at block 318 to deter- 
mine if the stored data field with the failure corresponds 
to the amount field for the item. If not, the image and the 
failed MICR data are sent to a workstation for image- 
based repair at block 320. A repair string is updated 
based on operator keying at block 322. The process then 
returns again to block 312 where it repeats if there are 
additional items to be corrected. Note that in this case, an 
operator only needs to correct one item at a time, and 
furthermore works with an image of the document rather 



than the document itself. Thus, within the steps shown in 
Fig. 3, working with paper rejects has been completely 
eliminated. 

[0027] Returning to block 318, if the error or failure is in an 

amount field, at least one additional OCR process result is 
obtained from a portion of the image at block 324. Thus, 
at least two portions of the image have an OCR process 
performed for a comparison of the result of an OCR pro- 
cess with the contents of a stored data field when the field 
corresponds to an amount. In this example embodiment, 
the OCR process is performed on the printed MICR and on 
a written, numerical amount. All three of these pieces of 
information can be compared at block 326. Note that de- 
pending on the OCR algorithms and processes used, in 
most cases it is possible to perform an OCR process on a 
written out amount as well as a printed numerical amount. 
This would involve at least three portions of the image 
having OCR results that can be compared with data in a 
stored field. In any case, the comparison is again used to 
determine how to correct an error in the stored field. At 
block 328, the result arrived at by this comparison is also 
checked against a minimum read confidence level. If the 
minimum level is achieved, the reject repair string data is 



updated at block 310. Otherwise, the image is sent to a 
workstation for image-based repair at block 320, as pre- 
viously described. 
[0028] Any of various known OCR algorithms can be applied to 
the process described in FIG. 3 to achieve the desired re- 
sult. Specific OCR products are available that have been 
designed to optically determine and read printed MICR 
characters, handwriting, printed amounts, etc. It is also 
known how to compare the results of more than one algo- 
rithm, or the results of an algorithm with stored values 
and make determinations within certain confidence inter- 
vals. One way of accomplishing this is via a voting algo- 
rithm. Optical character recognition is a mature art and it 
is readily understood in the data processing arts how to 
apply it to achieve various results. Various companies 
produce OCR products and systems for varied applica- 
tions, for example, ScanSoft, Inc. of Massachusetts, in the 
United States. 

[0029] FIG. 4 presents a system and network block diagram, 
which illustrates the operating environment for at least 
some example embodiments of the invention. Incoming 
paper items, in this case checks, are shown at 402. The 
documents are sorted and read at a high-speed sorter, 



404, for example, an IBM 3890 high-speed sorter. The 
checks pass through a capture area where read heads 
capture the MICR data and organize it into stored data 
fields. This data is transmitted to computer system 406 
via connectivity 408. This connectivity can be provided by 
any of various types of networks, for example, IBM System 
Network Architecture (SNA), an internal Internet protocol 
(IP) network, or a local area network (LAN). Computing 
system 406 stores the MICR data and any other required 
data on fixed storage media 410. 
[0030] | n the example of FIG. 4, electronic images 412 are cap- 
tured, forwarded to the computing system and stored. In 
the case of image cash letters, an image file 413 with 
string data and on-us items only would simply be pre- 
sented to the bank for settlement. No paper would physi- 
cally be exchanged. In this case, all activity resides (data 
and images) only in the computer based portion of Fig. 4. 
High-speed sorter 404 sorts all items which can be 
sorted, and routes the items into pockets 414. The sorted 
items include items with digit errors, as long as the digit 
errors are not in the routing/transit field. The sorting pro- 
cess allows items to eventually be packaged for movement 
to appropriate areas. In the example of FIG. 4, boxed 



transit items are shown at 416 and boxed on-us items are 
shown at 418. Items which cannot be routed, for example 
paper reject 420, are routed to a low-speed document 
processor, 422, for processing as a paper reject. Note that 
items that have been sorted for delivery to appropriate 
destinations, 416 and 418, can now proceed through the 
normal process, while the data is corrected using tech- 
niques based in computing system 406 and images stored 
in fixed storage 410. The techniques previously discussed 
relative to creating repair strings based on optical charac- 
ter recognition results and comparisons are directed and 
controlled by computer program code 424, at least in part 
stored in and read from fixed storage 426. Note that in 
order to handle cases where minimum confidence levels 
cannot be met by the OCR based algorithms, a number of 
operator terminals, 428, are interfaced to computer sys- 
tem 406 by Ethernet 430. 
[0031] it cannot be overemphasized that the system of FIG. 4 is 
provided as an illustrative example only. There are nu- 
merous types of document sorting machines that can be 
used to provide the sorting/capture/imaging functions. 
Most sorters typically have conventional document divert- 
ing mechanisms which route the documents to the various 



pockets. Sorting instructions to cause the documents to 
be routed are received from a processor within the sorting 
machine, or from an external computing platform, or 
sometimes both depending on the particular operations 
being carried out at any particular time. The computing 
platform can be a mainframe, server, workstation, and 
even a desktop or personal computer given the processing 
power that has been achieved in such devices in recent 
years. 

[0032] | n anv event, some embodiments of the invention can be 
implemented through extensive use of computer program 
products, or computer program instructions to carry out 
methods according to the invention. These instructions in 
combination with a computing platform processor and 
other devices form the means to carry out embodiments 
of the invention. These computer program instructions 
may be part of a computer program or multiple programs 
which are supplied as a computer program product. Such 
a computer program product may take the form of a com- 
puter readable media that allows computer program in- 
structions to be loaded into computing platforms. In the 
example operating environment of FIG. 4, a computer 
program product in the form of a medium containing the 



appropriate instructions is shown as removable storage 
medium 432. 

[0033] | n addition to being supplied in the form of a machine 
readable medium or media, computer program instruc- 
tions which implement the invention can also be supplied 
over a network. In this case the medium is a stream of in- 
formation being retrieved when the computer program 
product is downloaded. Computer programs which imple- 
ment embodiments of the invention can reside on any 
medium that can contain, store, communicate, propagate, 
or transport the program for use by or in connection with 
any computing platform or instruction execution system, 
apparatus, or device. The medium may be, for example 
but not limited to, an electronic, magnetic, optical, elec- 
tromagnetic, infrared, or semiconductor system or device. 
For example, the computing platform, storage mediums, 
connectivity, and sorting machine, can all be combined 
into one large device and the computer program instruc- 
tions could be stored within an optical, magnetic, or elec- 
tronic module type storage devices. 

[0034] | n order to more fully enable the present invention, the 
following details are presented on how strings within a 
CPCS system are updated and managed according to 



some example embodiments of the invention. As previ- 
ously discussed, the invention can be implemented in 
other types of systems. Detail on CPCS and CIMS is pre- 
sented as an example only. In an example CPCS system, 
good items that are sorted to pockets build an "l-String" 
within CPCS with a valid user byte. Items with digit errors 
that do not prevent sorting and all paper reject items 
build on the same "l-String" but, with other types of CPCS 
user bytes. 

[0035] items that are on-us with digit errors are sorted and build 
an "On-Us Reject String" within CPCS with an "On-Us Re- 
ject" user byte. Items that are transit with digit errors are 
sorted and build a "Transit Reject String" within CPCS with 
a "Transit Reject" user byte. Reject items, that is items 
that have digit errors in the routing/transit field or have 
other problems are sorted to a reject or "R" pocket for low 
speed processing and build a "Reject D-string" within 
CPCS with a user byte that signifies a paper reject. Thus, 
the CPCS entry will end and create four closed strings: I- 
String, On-Us Reject String, Transit Reject String and a 
Reject D-String. 

[0036] Transit reject string specified images and data will down- 
load to the OCR process. Certain digit errors will be cor- 



rected via this process if the logic can correct a failed digit 
with a specified confidence level. Similarly, on-us reject 
string specified images and data download to the OCR 
process. Items with digits failing in the amount field will 
go through an additional OCR/MICR/written amount veri- 
fication process to determine if handwriting, printed num- 
bers, or both can create a good read. Images and data for 
remaining items will download to workstations for digit 
correction via key entry by an operator referencing an im- 
age rather than a paper document. In some embodiments, 
on-us items go through the process of the invention with 
a low priority compared to transit items. 

[0037] Once all the transit rejects and/or all on-us rejects have 
been corrected for a specified entry, the "l-String" can be 
merged with a repair string(s) to create an Adjusted I- 
String or an "M-String" indicating the items have been 
corrected. In at least some embodiments, a final merge 
for all items in a batch waits until reject D-string specified 
items have been corrected. However, since employing an 
embodiment of the invention reduces the number of reject 
D-string items, the time involved in processing the batch 
is also reduced. 

[0038] Specific embodiments of an invention are described 



herein. One of ordinary skill in the computing, network- 
ing, and financial information technology arts will quickly 
recognize that the invention has other applications and 
can be used in other environments. In fact, many embodi- 
ments and implementations are possible. The following 
claims are in no way intended to limit the scope of the in- 
vention to the specific embodiments described above. 



